Extend protocol to support testing callback interfaces#19
Open
stringintech wants to merge 5 commits into
Open
Conversation
This adds skipped counts to suite and total summaries, prints clear timeout messages when remaining suites or test cases are skipped, and makes skipped tests cause a non-zero exit because not all tests completed successfully.
This changes output behavior by verbosity level: - quiet: print nothing for suites with no failures - on-failure (-v): print the suite summary, but hide passed test cases - always (-vv): print full suite and test output like before
Print each failed test case as '<suite-file> <test-case-id> (<test-case-description>)' above the total summary section in all verbosity modes.
extractRefsFromResult walks any Result value recursively to collect every {"ref": "..."} string it contains — covering both single-ref create responses and multi-ref array responses. The dependency tracker now uses this instead of the request's Ref field so refs nested inside results are tracked and their stateful dependencies are propagated correctly.
Handlers are expected to expose callback interface objects that record synchronous kernel callback firings into an internal queue and flush them on drain. The runner can then assert which callbacks fired, in what order, and with what values. Adds schemas, handler-spec documentation, a demonstration suite (testdata/callbacks.jon), and runner dependency tracking for the new protocol methods.
stringintech
commented
Jun 7, 2026
|
|
||
| When a callback fires, the interface implementation must, before the callback returns, append an invocation record to its queue, preserving firing order. The record identifies the callback that fired and carries its arguments, which may be primitives (e.g. an enum like `btck_SynchronizationState`, or a number like `verification_progress`) or objects (e.g. a `btck_BlockTreeEntry`). At this point object arguments sit on the queue and are not yet directly referenceable by the runner — they only become referenceable later, when [drain](#drain) registers them in the registry. | ||
|
|
||
| What the record carries for each object argument depends on how the kernel passes it. For arguments the kernel passes as owned copies, carry the copy directly. For arguments passed as views (pointers or references into kernel-owned memory), the handler must judge whether the underlying memory will remain valid long enough — at least until the last request that may reference this ref: if it will (e.g. a `btck_BlockTreeEntry` view that remains valid for the chainstate manager's lifetime), carry the view directly; if it will not — because the view points to a stack-local or other short-lived storage — copy the object before the callback returns and carry the copy instead. This decision is made at callback time; drain has no visibility into argument lifetimes. |
Owner
Author
There was a problem hiding this comment.
As documented here, handlers might need to copy callback args to extend their lifetime; but right now this is only needed for state in btck_ValidationInterfaceBlockChecked, a view into a stack-local. BlockChecked is also the only callback with mixed ownership: block arrives owned, state arrives as a short-lived view. A cleaner upstream contract might be to always pass object args as views and let consumers copy only when they need to outlive the callback - so block would become const btck_Block* too?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Please read the changes to
docs/hander-spec.mdin the last commit which explains the new design.This work is based on #17 and only the last two commits belong to this PR. I kept the other PR open in case any further improvements to the runner output is suggested.
Pre-release
v0.0.4-alpha.pr19.1tested in stringintech/go-bitcoinkernel#12 (comment).